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In an attempt to initiate a new approach to the 
teaching of Pascal, a study was conducted to ascertain the 
difficulties students encountered when they attempt to learn this 
computer language. Screening tests were given to 68 students in 
grader 11 and 12 who fcoJ just completed a semester course in Pascal. 
The purpose of the test was to detect possible difficulties in basic 
constructs such as reading and printing data, assignments, and the 
several control structures provided by Pascal. This test that showed 
over 50% of students had major difficulties with Pascal, and those 
problems are described, with notations as to whether the errors were 
frequent, or fairly frequent, or occasional. A group of 35 students 
were given a detailed clinical interview which is also described, and 
their~explanations of why errors occurred are given as well. A 
discussion of the data includes a summary of the investigators' 
assessment of the students interviewed and profiles of typical 
students. Finally, a comparison is drawn between this and similar 
studies, and the report concludes with a plan for future 
investigations which will include: (1) a lcMc at the difficulties 
high school students have with advanced conctots of Pascal and also 
with Logo; (2) an attempt to determine whether the errors noted in 
this study can be remediated; and (3) experimentation with different 
teaching/presentation strategies. (JB) 
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Abttrsct 



A screening test vss given to 3 classes of high school students, who 
were just completing introductory semester- long courses in Pascal. These 
tests were graded, and subsequently 35 students were given detsi led 
clinical interviews. These interviews showed thst errors were made with 
essentielly every Pascsl construct. Over hslf the students were 
classified ss having major difficulties — less thsn 102 had no 
difficulties. 

The errors noted are discussed in detail in this paper. / major 
finding is that the students attribute to the computer the reasoning 
power of an average human. The paper also speculates about how difficult 
it might be to remediate the errors found, and concludes with an outline 
of future work. 



9 

ERIC 



3 



- 2 - 



1- Introduction 

Hie growing availability and use of computers in the past few years 
has resulted in the introduction of programming courses in many schools. 
High Schools offer instruction in programming on the grounds that it 
provides students with needed job skills, that it is an important 
component of computer literacy, or that it is a powerful way to develop 
problem-solving and analytical thinking skills. Because programming, 
particularly in the high school curriculum, is a relatively new 
phenomenon, we have a limited understanding of how these students learn 
to program — the difficulties they have and the misconceptions they 
develop. Understanding these issues should serve an important role in 
improving instruction in this area as well as providing insight on the 
more general area of the learning of complex skills. 

It is widely accepted that to program effectively one must: 
. have a good knowledge of the syntax and semantics of the 

target programming language, (i.e. have an understanding of the 
- conceptual machine supported by the programming language) 
. be able to debug programs 

. be able to analyse (complex) tasks and design algorithms aimed at 
solving these tasks. 



ERIC 



4 



The ability to understand (or "read") program* it m by-produce of 
the firet two stag**. Further, it ia generally agreed that the topics 
are listed above in their order of complexity. That ia, taak analyeia 
and algorithm design are the moat demanding. Several researchers, 
including Sheil (1981), look at thia iaaue somewhat differently. While 
not necessarily disagreeing with the "accepted" wisdom, Sheil argues that 
when expert programmers are given a new task, they retrieve appropriate 
chunks (such as a loop to add N numbers) from long- tena memory and modify 
these to solve t ,e current task, (Shneiderman, 1976). Sheil argues that 
teachers of programming should be concerned about how to get novice 
programmers to this state, suggesting that the traditional approach may 
not be appronrtar*, I* several ether zrzzz, * PKv«^« and 
Mathematics, Cognitive Science researchers have noted that the 
organization of domain knowledge in experts is radically different from 
that of novices (see for instance Gentner & Stevens, 1983). The key 
educational question is how to produce instruct! sr* 11 sequences to 
effectively convey the content and structure of expert knowledge to 
novices. It is reasonable to suppose that Sheil would favour giving 
students complete programs to read, analyse and modify, and for each of 
these programs to contain one or more useful "chunks". (The detail of 
the language's syntax and semantics would then be introduced as secondary 
issues.) This is not a totally new idea (tze hovk 9 1971), and has been 
partially included in many introductory level /erfcity programming 
courses.^ 



Although intuitively we accept Shell's basic point, in this study ve 
were not able to initiate a new approach to the teaching of Pascal. 
Moreover we felt that further information about the difficulties 
experienced by students when tsught programing using "traditional" 
methods would provide additional empirical evidence. When we b?gan our 
study of programing classes in high schools, we expected to study the 
three stages noted above. However, it soon became clear that s 
significant number of students in the classes we studied had significant 
difficulties with Ehe first stage, and were thus hampered in their 
attempts to implement and extend programs. The first stage - students' 
knowledge of syntax and semantics- thus became the focus of this study. 

As noted earlier, one w-jer ccB?cr.c^t cf Icsrr.iujj Lu F k MK t« w 1* 
gaining an understanding of the "virtual machine" (Wegner, 1971) or the 
"conceptual machine" (Norman, 1983) underlying a particular language — a 
working model of how various constructs in a language function (DuBouliy 
& O'Shea, 1981). A programmer must know, for example, what happens when 
IF or READLN statements are used in a Pascal program. The current study 
explores some of the misunderstandings of the conceptual machi. a that 
■ome students hold in the early stages of learning to program in Pascal. 
We have concentrated primarily on their understanding of fundamental 
constructs such as variables, assignment, and several control constructs. 
"• have examined to a lesser extent their ability to trace and debug 
programs. 

DuBoulay and O'Shea (1981) provide a fairly comprehensive summary of 0 
earlier work on learning to program in commonly used lsnguages, including 



ERIC 



6 



BASIC, FORTRAN, LOGO, and Pascal. The Majority of the studies they 
reviewed reported the constructs of a particular language with which 
students had difficulty. Frequently the data provided included: 

— the constructs of the language that were roost frequently used; 

— the constructs of the language that were most frequently used 
incorrectly; 

— the error-pr oneness of these constructs (where error-proneness is 
the percent of total instances of a construct in which errors 
were made); 

— sooe idea of the persistence of particular errors (where 
persistence indicates the likelihood of them being removed). 

The first detailed analysis of the difficulties users have with 
Pascal vss undertaken by Ripley and Druseikis (1978) who did two studies. 
In their first study of computer science graduate students, they reported 
that 642 of the programs submitted were free of both syntsctic and 
semantic errors. In their second study of naive programmers, they 
reported that 582 of the programs submitted were again free of syntactic 
and semantic errors. With the latter group, the most comon syntax 
errors were associated with the misuse of the semicolon. The second most 
coauron source of error was declaration, because of the restrictions on 
the ordering of declaration keywords. Missing BEGINS and ENDS were the 
third most common source of errors; Ripley and Druseikis argued that 
these errors might be resolved if the language had more specific 
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terminators, e.g. BEGINTHEN, BECINELSE, ENDTHEN, ENDELSE, etc. to replace 
the "universal" BEGIN end END. 

More recently Solovay end hit co-vorkers have analysed the errors 
which university students make with assignment and loop constructs in 
Pascal. The majority of their analyses have been carried out on program* 
which have been collected automatically by the operating system, (see 
Soloway, Ehrlich, Bonar & Greenspan, 198?.). More recently they have also 
used interview techniques to probe students' understanding of the 
assignment com t rue t, showing that I:-I 4 1 and SUM:- SUM +N were viewed 
as different entitier; i.e., the pragmatics of the situstion dominated 
these students* interpretation (Bonar and Solovay, 1982). Another survey 
showed that 34* of the student = believed thct the WHILE statement iUed 
like a demon. 

With the exception of the study just mentioned, a major omission in 
all these studies is that they did not determine the nature of the errors 
associated with vsriovs constructs. They presented only the frequencies 
with which certain constructs were incorrectly used in progrems written 
by novice and sometimes expert programmers. Programmers who made errors 
were not questioned to determine the nature of their misunderstandings. 

Cognitive scientists working in other subject domains have 
postulated mental models which people hold of various physicsl and 
symbolic systems (Gentner & Stevens, 1983; Dsvis et al, 1978; Larkin et 
al, 1980). Such studies have relied heavily on interview techniques to 
reveal the nature of people's misunderstandings. We hsve applied this 
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Mthodology to study students' understanding of the conceptual machine of 
a programing language — their mental models of the language. 

The objective of this experiment vas to study the errors which 
students made in interpreting programs — and from these begin to 
understand the misconceptions of novice programmers. As a result of this 
study we hope to facilitate better teaching of programming — teaching 
that avoids or corrects these misconceptions. We also hope this study 
will provide some valuable insights into how students learn to work 
skillfully in a complex formal system. 

Method 

Subjects 

Students from thr»» h{ gh-p^Hrtoi ~ 1 ..s.a participated in the study. 
A pilot study wss done with one class of 27 students; two additional 
classes of 19 and 22 students respectively were involved. All three 
classes were introductory courses in Pascal.^ Our atudies took place 
towards the end of each course. The majority of the students were from 
grades 11 and 12 and had strong math backgrounds (as there were math 
prerequisites ) . 
Screening Test 

Prior to conducting the Pascal study we had carried out an analogous 
study of the difficulties students encountered when they learn BASIC, 
(Putnam et el., in preas). For the BASIC study we had developed an 
effective screening test and a set of more detailed question sheets 
focusing on particular topics. The task at the beginning of the Pascal 
study was to refine these tools (the test used is available from the 
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authors). The purpose of the test is to detect possible difficulties in 
basic constructs such as rcsding and printing dsts, assignments, snd the 
several control structures provided by Pascal. Nine items require 
writing the output produced by short (6 to 14 line) program, esch 
designed to highlight specific conceptCs). One task requires the 
student to debug a program for which a written description of the intent 
has been provided. Two items sddress a similar task, but esch program 
uses s different control structure. The test took between 15 end 35 
minutes for the students to complete. Because we asked questions about 
programs which we hsd prepared, only the students* reading knowledge of 
Pascal was tested. It would sppear that creating a program would be more 
complex than understanding 4 given (short) nrnoram *nrf mn wo Sugg*?? 
that this test represents a test of minimum competence. 

The screening test was pretested with a class of 27 students. Minor 
changes were made in the test before it was used with 2 additional 
classes. In general the test and the questions used in the interviews 
were fine-tuned for each class to reflect the teaching materials used, 
the order in which concepts had been introduced, etc. 
Experimental Procedure 

The screening test was given to each student in the three clssses. 
Each student's performance was evaluated by one of the researchers who 
decided that the student fhould be interviewed, was a marginsl candidate 
for an interview, or did not need an interview (depending on whether the 
student hsd minor or no difficulties, or manifested a well understood set 
of misunderstandings ). Interviews were conducted with 9, 15, and 11 
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students respectively from the three classes (in the esse of the first 
class it was not logisticslly possible to interview all the students for 
whom an interview was suggested). The interviews were clinical in 
nature, with interviewers using questions and short progress prepared in 
advance, but also following up with various probes and progress composed 
on the spot. The goal was to clarify as far as poisible the mature and 
extent of the student's misconceptions about programing concepts. 

Students were asked to say what output would be produced by various 
programs, to trace programs and explain how they work, and to debug short 
programs. In several cases, students were asked to trace identical 
programs with different sets of input data. The discussion of a 
p^rlftwulat %.upic fctuculiy continued unci! the researcner was able to 
decide: i) the "precise" nature of the student's error, or ii) that the 
student had a variety of possible ways of interpreting a construct, or 
iii) that che student had little knowledge of a particular concept. The 
interviewer also made a subjective assessment about his or her confidence 
in this prediction and also noted how consistently the student had 
manifested the several error(s) (for further details of this overall 
methodology see Sleeman, in preparation) • the standard programs and 
program fragments used in many of the interviews are available from the 
authors. Some supplementary items created for individuals are included 
i^s the text. 

Tape recordings, written notes, and responses generated during the 
interviews were perused for patterns of errors and misconceptions. As 
the study was exploratory and qualitative in nature, no quantitative 
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analysis techniques vere used. Findings are discussed in the following 
sections. 

Section 2 gives an overview of the errors encountered, vith some 
indication cf the frequency of their occurrence. Section 3 gives several 
summaries of the data - including a diacussion of typical students vith 
minor and major dif f iculties, and a classification of the errors noted. 
Section 4 compares the results of this experiment vith earlier studies. 
The psper concludes vith suggestions for future studies, 

2. Summary of Errors Encountered 
A comment on error frequency 

As noted above, the screening tests vere given tc 68 students ot 
which 35 vere subsequently interviewed. We shall refer to an error as 
being frequent with this population if it occurs vith 25Z or more of 
the interview population" (i.e, 8 or more students), fairly frequent 
if it occurs vith 4-7 students, and occasional if it occurs less 
frequently (i.e. vith 1-3 students). Note this figure does not capture 
the frequency or the consistency vith which each error was encountered 
with individual students; specific comments about these aspects will be 
interspersed throughout this section. 
2.1 Difficulties with READLN statements 

Several students had difficulty understanding how a READLN statement 
assigns values to a variable. Four categories of misconceptions 
appeared: semantically constrained reads, data read in alphabetic order 
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of the variables, order of declaration determine! the order of reading 

froa the file, and sulci pie-value reads. 5 

Seaantically constrained reada IlCla.l] 

Eleven atudents believed that a READLN stateaeat used with a 

Meaningful variable name causes the program to aelect a value baaed on 

the name 1 a meaning. (Thus given the frequency classification given 

earlier thia is a frequent error). For exes; le, given the following 
6 

program: e 



PROGRAM Bl; 

VAR First .Smallest .Largest: INTEGER; 
BEGIN 

WRITELN( 'Enter three numbers'); 
READLN (Large at , Smal lest .First ) ; 

END. 

[ 5 10 1 ] 



The students with this error said that 1 would be read into "smallest", 
10 into " largest" and 5 into "first". The majority of these atudenta 
exhibited this error consistently on this program and in two other 
programs where it could occur. The aecond program used to probe for th 
error was: 



PROGRAM B2; 

VAR Even, Odd: INTEGER; 
BEGIN 

WRITELN( 'Enter two numbers'); 
READLN(Odd, Even) ; 

END. 
[23] 



13 



Ten etu&ents read 3 into "odd" end 2 into "•vtn". 
Order of declaration determines the order of reading 

This wet e feirly frequent error end it eh owed up with: 



PROQUM B4; 

VAR A, B,C: INTEGER; 

BEGIN 

WRI TEL NC Enter three numbers'); 

readlncc, b,a) 

END. 

I 15 25 20 ] 



These student, ergued thet A wes es signed the first number, B the eecond 
number end C the third number "because of the order the veriebles were 
declared". Typically the interviewer then modified the order of the 
variable declarations , end asked the students to rework the tesk. In ell 
cases the response was consistent with this error. 
Multiple-values reed into e variable 

This frequently occuring error was noted in: 



PROGRAM B3; 

VAR Even, Odd: INTEGER; 
BEGIN 

WRITELNC 'Enter data: '); 
READLN(Even,Odd) 

END. 

f 3 2 10 5 } 



14 



- 13 - 

These student* consistently and confidently said that "even" was assigned 
the values 2 and 10 and "odd" 3 and S. The data set was then frequently 

a 

added to and the students continued to manifest this error. Further, 
when multiple-valued variables occur in a conditional statement these 
students either said that the first value is used for comparison or 
that the comparison cannot be made or the program loops until the values 
in the variables have been "used". 
2.2 Difficulties with print statements 

The following three errors occurred occasionally with WRITELN 
statement s: 

a) WRI TEL N( 'Enter a number: *> caused a number to be read; similarly 
WRI TEL N( 'Enter 4 numbers; ' ) caused 4 numbers to be read. 

b) WRI TEL N( 'Enter s number: ') caused the variable name and its 
value to be printed. 

c) After this ststement has been executed the program can choose a 
number from the data statement. 

After we had encountered these students the following diagnostic 
sequence was devised: 

X:- 3; 

WRI TEL N( 'The vslue of X is 1'); 
WRITELN(X) ; 

All subsequent students who did not have the errors noted above were able 
to cope with this correctly, but we are confident that the itudents with 
this error would have given the answer "1". This item has been added to 
our repetoire and will be used subsequently. 
2.3 Assignment statements 



9 

ERIC 



15 



The first item of the screening test vss designed to detect 
difficulties with assignment statements and supplementary examples 
produced for the interviews probe this construct further. Although the 
several errors only occurred occasionally, a total of nine ucudents had 
difficulties with assignment ststements. The difficulties noted include 

1. A:- B was interpreted as switching variables, A:-B and B:«A (3 
students showed this error). 

2. The assignment statement causes the instantiated statement to be 
printed. Given the sequence A:-2; B:»3; A:-B; one student said the 
computer would print 2 « 3. 

3. The assignment statement had no effect (noted with 3 students). 

4. A:» B was interpreted as A - B by 2 students. 

2.4 Variables 

The most significant "variable" error was the previously mentioned 
multiple value error. The following errors have also been noted 
occasi onally: 

1. Confusion of variables. In the sequence: 

READLN(P); Q:« Q+l; 

the latter statement is executed as if it were: 
Q:" P+l; 

2. Values of variables are printed when the variable is encountered on 
the LHS (left-hand side) of an expression. 

3. The value of the LHS variable is printed whenever its value changes. 

2.5 Difficulties with loop constructions 

A. Errors Common to both the FOR and WHILE constructs: 
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1. WRITELN adjacent to the loop ia included in it . UIIA2.1}. This 
error occurred frequently end wee noted with nearly half the student* 
interviewed. The program* which highlight this are: 



PROGRAM G3; 

VAR P,Q: INTEGER; 

BEGIN 

Q:- 0; 

yp.ITE( 'Enter a ouober: 
kEADLN(P); 
WHILE P <> 0 DO 
BEGIN 

IF P > 0 THEN 

Q;«Q ♦ 1; 
WRITEC 'Enter a number: '); 
REAOLN(P) 

END; 

WRI TELN(Q) 

END. 

( 1 -1 -3 2 4 0 J 



and 



PROGRAM A5; 

VAR I,X: INTEGER; 

BEGIN 

FOR I:- 1 TO 3 DO 
BEGIN 

WRITELNC Enter a number.'); 
READLN(X) 
END; 

WRITELN(X) 

END. 

[ 6 3 4 2 4 1 8 ] 
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Curiously enough, thoie students who consistently sake this error with 
the WHILE problem do not necessarily make it with the FOR loop, and wise 
versa* 

2. Data-driven Looping 

Several students indicated that the number of numbers in the data 
determined the times a loop was executed. Thus given the program: 

PROGRAM A2; 

VAR I, X: INTEGER; 

BEGIN 

FOR TO 3 DO 

BEGIN 

WRITELN( 'Enter a number.'); 

READLN(X) ; 

WRITELN(X) 

END 

END. 

16 3 4 2 4 18] 

We have observed the following output: 

6 3 4 2 4 18 
6 3 4 2 4 1 8 
6 3 4 2 4 1 8 

The students explained that the number of values in the data set 

a 

determined the number of columns, and the value of the FOR-loop limit (in 

this case 3) determined how many times the process was repeated. 

Given 6 2 as input data this same student produced the following output: 

6 2 

6 2 

6 2 

ERIC x 0 
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3. Scope problems 

Several errors involved misconceptions stout which statements ere 
repeated in loop! and where loops begin and end. 

•) Only the laat instruction of a loop ie executed multiple tines . 
The other instructions are only executed once but the last instruction is 
executed the correct number of tines. This error was noticed fairly 
frequently, but it only occurred in a loop where a WRITELN statement was 
the last one in the loop (thus it nay be this error was caused by the 
write statement and not the loop construct). 

b) BEGIN/END defines s loop. Two students thought that all the 
numbers in the data set would be printed despite the absence of a FOR or 
WHILE statement. The program is: 

PROGRAM A3; 

VAR X: INTEGER ; 

BEGIN 

WRI7ELN( 'Enter a number.'); 

READLN(X); 

WRITELN(X) 

END. 

[ 6 3 4 2 4 1 8 ] 

T a variant on this error, scope of the loop is determined by 
indentation. In the case of some other programs, several students said 
that the WRITELN "went together with the FOR loop because they were lined 
up". One such program is: 
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PROGRAM Di: 

VAR R, C: INTEGER; 

BEGIN 

FOR R:» 1 10 4 DO 
BEGIN 

FOR C:* 1 ID 3 DO 

WRITE (***); 

WRITELN 
END 

END. 



c) After a loop is executed control goes to the first statement of 
the program. This error was seen occasionally and in short prograns 
could be interpreted as re-initialising variables each loop-cycle. 

Although each of the scope errors in loops only arose occasionally, 
the total number of students vho had difficulties vith the scope concept 
vas approximately one third of thoae interviewed. 
B. triers specific to FOR loops 
We will just note 2 additional errors* 

1 „ The control variable does not hsve a value inside the loop. (This 

occurred fairly frequently.) 
2. The FOR loop statement acted like a constraint on the embedded 
READLN statement. A student said that only the numbers 3 t 2, and 1 could 
be read with; 
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PROGRAM AS; 

VAR Jt.X: INTEGER; 

KGIN 

FOR I:- 1 TO I DO 

KGIN 

WRITELNC "Enter a number.* >; 
READLN(X) 
END; 

WRITELN(X) 

END. 

{ 6 3 4 2 418] 



Although vith thii group of Pascal students this error only occurred 
once, we have previously noted it occurred frequently vith students 
learning introductory BASIC. 



2.6 Errors noted with IF statements 

Four types of errors were noted occasionally with IF statements. 
However, 8 students (or 25%) made at least one of the errors: 

1. Program execution is halted if the condition is false and there is no 
ELSE branch. 

2. Both the THEN and the ELSE branches arc executed. 

3. The THEN- statement is execr»ed whether or not the CONDITION is true. 

4. IF <a> THEN <b>; <c>; is interpreted as 

IF <a> THEN <b> ELSE <c>; 

2.7 Errors with procedures 

These errors fell into two categories: 

1. All statements including those in procedure bodies were executed in 
the order they appeared. This was a frequent error. 
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2. A fairly frequently occurring variant ia that procedure* are executed 
when they are encountered in a top- to-bottom acan of the program text and 
again when they are called. 
2.8 Tracing and Debugging 

Ai noted earlier tracing and debugging were not emphasised in this 
study, but ve did include a program in the screening test and a program 
in the eubsidary Material which highlighted these issues. Further, 
interviewers frequently asked students to trace some of the other 
programs if they thought this would help determine the nature of the 
students 1 difficulties. From this activity 9 the several interviewers 
concluded that at least half of the students could not trace through 
programs systematically. Further, we concluded that these students often 
decided what the program should do on the basis of a few key statements y 
and would then "project this insight" onto the program as a whole. 

1. Some students 1 interpretation of the following program ia 
dominated by the variable Smallest — "obviously this program is to find 
the smallest of a set of numbers 11 . Thus this program highlights a 
variant of the semantic read misconception: 
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PROGRAM II; 

VAR Sullnt, Nuaber: INTEGER; 
BEGIN 

WRITELNC 'Enter a nuaber: ' ); 
READLN(Nuaber); 
Smallest:* Nuaber; 
WHILE Saa licet <> O DO 
BEGIN 

IF Sulltit > Nuaber THEN 
Sulltit:* Nuaber; 
WRITELN( 'Enter a number: •); 
READLN(Nuaber) 
END; 

WRITELN( Smallest ) 

END. 

[ 9 5 6 2 0 ] 



These student assume that the first READLNC Number) statement resds the 

lowest value from the data line because, the smallest nuaber is needed in 

the next statement, Smallest: "Number. This error was noted occasionally. 

2. Students' interpretation of several programs relied on what 

would be reasonable output, rather than the actual output statements in 

the program: 

PROGRAM F2; 

VAR Number: INTEGER; 

BEGIN 

WRITE( 'Enter a Number: 1 ); 

READLN(Number); 

IF Nuaber - 7 THEN 

WRITELNC 'Unlucky Number'); 
IF Nuaber - 10 THEN 

WRITELN( 'Lucky Number'); 
WRITELNC 'The Number was', Number) 

END. 



[ 4 1 i 10 ] { 7 } 

For instsnce when the nuaber 10 was read, students said soaething like 
"Well it will print LUCKY NUMBER and that's all as there's no point doing 
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Che next line as ve know the value stust bm 10 mm it's e lucky number", an 
analogous explanation was given for the UNLUCKY number. These 
explanations were encountered frequently* * 



3. Suwnary of the data 
The data is both rich and complex and so ve shall attempt several 
overviews each of which will highlight some aspect. 

Figure 1 

S unwary of Investigators 1 Assessment of Students Interviewed 



Male Female Tott! 

No difficulties 3 (8.62) 0 (0%) 3 (8.6%) 

Minor difficulties 6 (17, 142) S (22,93!) 14 (40Z) 

Major difficulties 12 (34.28%) 6 (17.142) 18 (51.42) 



21 14 35 

3. 1 Summary of all the students interviewed 

Incorrect variants of virtually every construct in the Pascal 
language were found with these students. At least 32 atudents out of the 
total population of 68 students had minor problems, and 18 of them (or 
272) had major difficulties. Anecdotally 9 teachers report that atudents 



ERIC 



24 



- 23 - 



debug programs by a "triel-and-error" method. This study lends support 
to Chit view, as, in the case of oany students, several Pascal constructs 
are only partially underatood (or subject to multiple interpretations), 
thus waking a trial-and-error approach the only realistic alternative! 

This study shows that even after a full semester of Pascal, 
students 9 knowledge of the conceptual machine underlying Pascal can be 
very furry. This is a more widespread problem than we had expected and 
one which is not totally appreciated by the teachers who frequently set a 
performance- based completion criteria for the class. Not unreasonably, 
programming taaks are completed jointly by several student a often masking 
the several misunderstandings of the individual students. 

Each interviewer claaaified each student's performance as having 
essentially no difficulties, minor- and major-difficulties; this 
information is tabulated in figure 1. Prom this figure we note that 3 of 
the students did not have any problem in the interview although the 
screening test indicatea they had. In most cases this has been 
attributed to the students rushing the test or not taking it seriously. 
(Note: all 3 were males). Of the remaining students, the figures show 
they fall nearly equally between those who have minor and major 
difficulties. However there is & greater proportion of males who had 
njor difficulties than females, namely 12/18 males (66.6Z) had major 
difficulties as compared with 6/14 (42 .92) females. (These figures are 
based on the population interviewed and not the total numbers screened). 
Interestingly, our assessment of the students closely with the teacher's 
evaluation. 
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3.2 Profiles of typical students 

So far in this paper we have given an account of the errors which 
have been noted in the population with acme indication of the number of 
students who manifested that error. By way of contrast, in this section 
we will describe all the difficulties noted for two students; one was 
described as having minor difficulties and the other having major 
difficulties. 

Example of a student with minor dif f icult ics . 
This student appeared to have two errors; 

1. Assignment being interpreted aa a switch 

A: * B is interpreted as A:* B and B:» A. 
(The student did not manifest this behavior consistently). 

2. Statements in procedures are executed as they are encountered. 

(The student appeared to be consistent with this error)* 
Note too that when we interviewed this class, procedures had only 
recently been introduced. 

Example of a student with major difficulties * 
The errors reported with this student were: 

1. Semant ically constrained reads (a consistent error). 

2. The alphabetic ordering of the ariables determines the order in 
which the data is read (not applied consistently). 

3. Read a value when a variable is encountered in a statement (not used 
consi stent ly) . 

4. WRITELN( 'Enter a Number 1 ) causes a value to be read (not used 
consistently) . 
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5. VRITELN adjacent ro a loop construct is considered a part of Che loop 
(a consistent error). 

6. The oumbar of data element • determines the number of times a loop is 
executed (a consistent error). 

7. The control variable does not have a value in the loop body. 

8. The order of execution of 2 statements was inverted consistently in 
one program: 

PROGRAM Gl; / 

VAR Number; INTEGER; 

BEGIN 

Number;' 0; 

WHILE Number < 5 DO 

BEGIN 

WRITfcLN(Number); 

Number: 'Number + 1 

END 

END. 

was executed as if the loop body was; 

Number;-. Number ♦ 1; WRITELN(Number); 

However, this behaviour was not noted with other programs. 

9. Infer program function based on a number of commands. 

A section of the interview with this student is quoted in section 
2.8 where this error is described. Essentially we believe this student 9 s 
interpretation of the program was dominated by several key statements in 
the code , and the notion that the machine would act "reasonably". Why, he 
I argued, would the machine execute the last VRITELN which gives you the 
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value of the number, when it has already told you that the number vat 
lucky and so you'd know it had the value of 10? 

We have classified this student as having major difficulties not 
only because of the sizeable number of difficulties but because we 
believe some of the misconceptions will be hard to remediate. For 
•sample, we believe that the last 2 errors (8 and 9) will be difficult to 
remediate aa here the student is calling upon a lot of common-sense 
knowledge. This issue will be discussed again in section 3.3. 
3.3 Error clsssif icstion 

Implied at the end of the last 'tbsection is the belief that some 
misconceptions will be much easier to remediate than others. In the 
algebra domain, for instance, Sleeman has suggested that some errors 
occur because the user omits one of the substeps of s rule which he 
essentially knows; we have called these manipulative errors (Sleeman, 
in press). Other errors indicated that the student has little 
understsnding of basic concepts in the slgebra domain. For example we 
have seen the expression 

3 X * 4 X - 19 changed to X ♦ X - 19 -3 - 4 
We hsve referred to errors of this sort as being parsing errors. To 
generalise this classification to programming, and possibly to other 
domains, we propose referring to these classes of errors as surface and 
dggp errors. 7 We suggest that an example of a surface error in this 
domain is seeing the FOR loop with range 0 to 5 as 1 to 5. Lack of 
understanding of variables is a complex issue and we suggest should 
be classed ss a deep error. As indicsted earlier we believe that the 
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inference of the functionality of a program from a few key instructions 
it a deep error and one <hich arises from the user bringing coaeon sense 
reasoning to bear on a formally defined domain. In addition to this 
issue we believe that many of the errors noted, for example, semantical ly 
constrained reads can be explained by the user attributing to the machine 
the reasoning power of an average human. We refer to this subclass of 
errors as the "reasonably human" error class* 

4* Comparison with the difficulties noted in this and other studies 

Finally ve should recall that for the most part ve have presented 
students with syntactically correct programs hence the significant 
difference in these findings and those of Ripley and Druseikis, 1978. 
However, we noticed that these students had considerable problems with 
the notion of scope (which supports Ripley & Druseikis's third 
observation, see section 1). Moreover, we generally noticed that the 
students we worked with had only a fussy idea of syntax, and we would not 
be surprised if they made the types of punctuation errors noted in the 
earlier study in their own programs. 

With our students, only one student out of the 35 interviewed 
treated the WHILE statement as a demon, a marked contrast to the Yale 
data* 
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5. FURTHER WORK 

We plan to: 

1. look at the difficulties high-school students hsve with sore advsnced 
concepts of Pascal (in this study we only touched upon procedures); 

2. investigate the difficulties which high-school students hsve with 
LOGO (to give us a third point of reference); 

3. determine whether it is possible to remediate the sort of errors we 
noted in this study. If this is possible, try different remedial 
strstegies to determine their effectiveness; 

A. speculste further about how such Misunderstandings srise snd possibly 
experiment with different teaching/presentation strategies. 
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Footnotes 

1. Also Computer Science Department. 

2. Lemos, (197S) eleims thet the epproech of Analysing coop I etc progress 
was no more effective then the traditions I one — however, ve feel thst 
this isiportent lins of investigation should not be abandoned beceuse of s 
single negative data point. 

3. That is given a WHILE at* cement of the form: 

WHILE cond 00 
BEGIN SI; 

• 9 • 

Sn 

END 

after executing a statement Si, of the WHILE body they would check to see 
whether the 00 ND is still true, if not they would skip the remaining 
statements. 

4. Most students had some prior exposure to BASIC; the effect of s 
previous programming language on a second lsngusge is en issue to be 
considered in a further study. 

5. It is difficult to categorise unambiguously many of the errors noted. 
For example: is the lest error mentioned s "READ" or a "vsriable" error? 
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In this paper we make an arbitrary assignment to a class which seems 
reasonable; in some cases we discuss possible alternative categories. 

6, The convention used in this and subsequent programs is that the data 
Ma provided in brackets immediately following the program; multiple 

brackets indicates multiple sets of data. 

7, Following the recent distinctions introduced to designate the level 
of an expert system's knowledge of its domain. 

8, Also encountered in algebra (Kuechemann, 1981), 
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